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ABSTRACT 


Manual formal software verification is an expensive and time-consuming process. 
Military software is currently verified manually by highly skilled analysts. To reduce the 
high costs of the formal verification, DARPA started a Crowd-Sourced Formal 
Verification (CSFV) program that aims to include as many people as possible to 
participate in this verification process by embedding some of the verification logics into 
computer games. In this study we built a network prototype for hosting a CSFV server on 
a DoD network. 

The CSFV network prototype is designed according to the common security 
practices, necessary security measures against possible attacks, and the Security 
Technical Implementation Guides (STIGs) published by DISA to provide confidentiality, 
integrity and availability. Important details are presented about server operating system 
selections, proper usage of necessary network services, and firewall and IDS rules for 
efficient network security. Results from common network penetration test tools confirm 
that our prototype meets the necessary security requirements and can be trusted on a DoD 
network. 
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I. INTRODUCTION 


A. INTRODUCTION 

In 2014 cyber attacks on critical infrastructure are expected to increase 
significantly and consequently cause security expenditures to reach a peak of $86 billion 
(Rivera, 2013). Even after all the attention devoted to this threat, cyber-related problems 
do not seem to be resolved. According to the task force report of the Defense Science 
Board, the advanced cyber threat the Department of Defense (DoD) faces is too 
prevalent, and critical IT structures may stop functioning in case of a sophisticated and 
well-resourced attack vector (Kaminski, 2012). This threat becomes even more disturbing 
when we realize that a malicious user can cripple the Unified Threat Management System 
(10 million lines of code) with a malware (125 lines of code) (Dean, 2013). 

Being under the cyber threat of its opponents, the DoD has taken the necessary 
precautions in different areas. One of those areas is the formal verification of military 
software, which is used to process classified information. One to five bugs are found in a 
thousand lines of code of military software, and most of them are related to security 
vulnerabilities. 

Currently formal verification is performed manually by very specialized engineers 
and this is a very expensive process (Dean, 2013). The Defense Advanced Research 
Projects Agency (DARPA) initiated a project to lower the costs of the verification 
process and increase the efficiency levels by harnessing the power of a crowd. Crowd 
Sourced Formal Verification (CSFV) aims to perform the necessary software verification 
by creating computer games, which are fun to play. The goal is to make the crowd play 
the games and have the military software verified in the background. Even though it 
sounds innovative to use the crowd to solve a problem, it is not a new concept. 
Crowdsourcing was used by DARPA before to design a next-generation combat vehicle 
and to reconstruct shredded documents, such as those found after military engagements 
(Montalbano, 2011). 
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DARPA plans to run its CSFV systems on the Internet—possibly using eloud 
infrastrueture (Dean, 2013). By using Amazon Compute Cloud (EC2) systems, DARPA 
will use ordinary people and make them play the games, whieh will enable the software 
verifieation with the help of eomplex algorithms. 

This thesis aims to design and prototype a secure network for CSFV systems, and 
this network will be run on a limited access intranet such as the Defense Research and 
Engineering Network (DREN), whereas DARPA’s initial gaming environment will exist 
on the Internet, open to everyone. 

B, THE RESEARCH PROBLEM 

1. Problem Statement 

DARPA’s CSFV systems are designed to reside on the Internet, and they 
welcome anyone to log on and play the games. However, there is currently no network 
architecture to run the games on classified intranets such as DREN, the Non-classified 
Internet Protocol Router Network (NIPRNET) or the Secret Internet Protocol Router 
Network (SIPRNET). 

2, Purpose Statement 

The purpose of this thesis will be to design and prototype a secure network 
architecture for implementing Crowd Sourced Formal Verification methods on 
classified/unclassified networks. 

C. RESEARCH QUESTIONS AND HYPOTHESIS 

In this thesis these research questions will be answered and explained; 

1. What are the common security threats and solutions for securing enterprise 
network resources? 

2. What are the key benefits of virtualization, and how can virtualization be 
implemented on DREN while meeting security requirements? 

3. What are the possible security concerns of cloud computing? 

4. What are the unique security challenges for deploying CSFV on DREN? 
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D. THESIS ORGANIZATION 

Chapter I; “Introduction” (Introductory information about formal verification 
issues and the need for efficient software verification) 

Chapter II; “Background” (Review of definitions and details of concepts related 
to CSFV such as crowdsourcing, cloud computing, virtualization and enterprise network 
security) 

Chapter III; “Network Design” (Design of optimally most secure network in 
regard to the potential security vulnerabilities/threats specifically for CSFV networks) 

Chapter IV; “Implementation” (Creation of the CSFV network prototype) 

Chapter V; “Conclusion” (Summary, future work and recommendations) 
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II. BACKGROUND 


A. INTRODUCTION 

This chapter will summarize the eore eoncepts that will be reviewed in this thesis. 
In the following seetion basic information about crowdsourcing will be presented, 
ineluding its history, eurrent use, and vast benefits. Seetions C and D will explain two 
neeessary platforms for CSFV systems, whieh are virtualization and eloud-eomputing. 
Finally this ehapter eoneludes with information about the eurrent eyber security threats 
pertaining to CSFV networks. 

B. CROWDSOURCING 

Crowdsoureing provides a workspace to be used for a large seale of aetivities. 
These activities vary from journalism to image indexing and from language translation to 
entertainment (Howe, 2009). Crowdsoureing is the outeome of two words: “erowd” and 
“outsourcing” and is meant to aeeomplish something with the help of untrained, ordinary 
people, rather than professionals and experieneed employees. The erowd may be drawn 
from either a large or small population. The aetivity, whieh is done by the erowd may 
help for projeets sueh as designing a task, developing a teehnology, solving an algorithm 
or elassifying, eolleeting or analyzing large amounts of data (Bell, 2010). Nowadays 
typieal examples of erowdsoureing are ereated online, but the first examples of 
erowdsoureing were quite different. Organizations have leveraged erowdsoureing 
solutions throughout history. 

1. A Brief History of Crowdsourcing 

The history of erowdsoureing dates baek to 1714 when the Longitude Contest was 
organized by the English government. The purpose of this eontest was to enable the 
government to find a prototype of a navigation device, whieh might even be developed 
by a eommon citizen, to help sailors navigate easily (Lynch, 2010). Another early 
example is the Toyota Logo Contest in 1936. Twenty-seven thousand people attended 
this event, and the best design ereated by someone in this erowd was ehosen to be the 
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Toyota Logo. In 1955 the Sydney Opera House was also designed and built as a result of 
a publie contest, which encouraged ordinary people from 32 countries to help this design 
project (Lynch, 2010). 

2. Current Crowdsourcing Activities 

Crowdsourcing provides opportunities to solve the chronic problems worldwide 
that have been waiting to be solved for years. The diverse base of knowledge and abilities 
is unlimited in a crowd. The technique of crowdsourcing would match this diverse base 
with the needs of people using this technique (Howe, 2009). Currently crowdsourcing 
activities around the world are increasing rapidly. Most IT companies are handing their 
technical support elements to forums in which users share knowledge. In journalism, 
sector leaders like Reuters and the BBC are increasingly choosing public resources to 
crowdsource important work, such as investigating government wrongdoings or reports 
about local events. In March 2009 public opinion was largely gathered and analyzed 
through the White House website, and those results greatly affected political 
decisions (Howe, 2009). 

Another area of crowdsourcing is the freelance sector. Although it is a local 
Chinese firm, the freelancing website Zhubajie.com has more than seven million 
subscribers, and it is still growing (Lynch, 2012). Such growth is hardly surprising. It is a 
fact that a large population helps a lot in crowdsourcing. In the following subsections 
some globally known crowdsourcing examples will be presented along with some local 
examples. 


3. Linux Kernel 

Open source software development projects inherently allow users to see, change 
or add code freely to the already developed software. In the 1990s this open source 
development environment enabled the creation of an important product, Linux. Its 
creator, Linus Torvalds, declared that the operating system that he had developed was 
open to any critics, and he was looking for others who could help improve it (Howe, 
2009). By getting the crowd’s help, today Linux is in use everywhere—from 
supercomputers to hand-held devices. 
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4. 


reCAPTCHA 


Originated at Carnegie Mellon University by Professor Luis Von Ahn, 
reCAPTHCA is designed to digitize the text in the books. It has been used to digitize The 
New York Times arehives. Another use of reCAPTCHA is to proteet websites from bots 
that are designed to infiltrate the restrieted areas in the network (Bell, 2010). 

reCAPTCHA provides websites with the images of words that bot software is 
unable to read. The registered websites help verify these images and present them as 
CAPTCHA words, and the words are sent to digitization projeets. This serviee is 
ealeulated to provide 12,000 man-hours per day of free labor (Bell, 2010). Popular 
websites sueh as Faeebook, Twitter and Tieketmaster are effeetively using this serviee in 
the eustomer validation proeess (Bell, 2010). 

5. Games with a Purpose (GWAP) Project 

Another applieation in the vast area of erowdsoureing is using simple games to 
aehieve a purpose that is mueh more valuable than just relaxing. Beeause billions of 
people ineluding ehildren are interested in games, and maybe millions of them are 
spending several hours daily playing games, seientists thought that these valuable hours 
eould be used benefieially in parallel with the fun part. Carnegie Mellon University 
Professor Luis Von Ahn ereated the GWAP projeet to use game playing hours for a 
soientifieally valuable purpose, sueh as Internet image indexing, monitoring seeurity 
eameras and performing language translation (Ahn, 2006). Other possible applieation 
areas eould be IT seeurity, Internet aeeessibility, adult eontent filtering, and web seareh 
(Ahn, 2006). The main idea behind this projeet is to have people play games and use the 
results of the games for another purpose. One of the most popular of these games, the 
ESP game designed by Ahn, is designed for two players. These players must agree on the 
best word that represents the image presented to them. They do this without knowing that 
they are seeing the same image (Bell, 2010). 

The eoneept of playing games is applied to other areas as well. A game sueh as 
“Foldit,” whieh was designed by researehers from the University of Washington, allows 
users to play with protein-like struetures by folding and unfolding them. When the 
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protein structure is modified games scores are automatically recorded with regard to the 
success level of how accurate the folding is (Bell, 2010). 

6. Verification Games: Making Verification Fun 

This project is directly related to the CSFV concept, and it aims to make people 
play games as a part of the CSFV project. Ernst (2012) investigated ways to lower the 
costs of software verification by developing game-playing-based verification systems. In 
his latest work he introduces and explains the technique he used in the game “Pipe Jam,” 
which is used to map a software and to correct potential problems in that software. 

His game is comprised of boards, levels and worlds in which the gamer plays with 
pipes that are linked to each other. The gamer tries to pass a ball into different sizes of 
pipes. The width of a pipe represents the type of variable that the pipe represents. A wide 
pipe stands for a variable that is permitted to contain a “null” value whereas a narrow 
pipe represents a variable that is guaranteed to be non-null. 

As with the general concept of CSFV, a gamer does not have to know anything 
about the software he helps to verify. Gamers do not have to have confidentiality 
privileges, and they can be anyone from public. 

The Pipe Jam game is analogous to the dataflow network for a program. It maps 
the source code’s type flow properties into a network of pipes. Essentially, this system 
converts the software into a game that can be played by ordinary people. After the player 
finishes a portion of the game the final board configurations can be translated into a proof 
of correctness for the original program (Ernst, 2012). 

a. Amazon Mechanical Turk 

Amazon Mechanical Turk is a platform where organizations find 
employees for their projects. Amazon Web Services provide this platform to match the 
job requesters with the potential workers who can be anywhere around the world. Job 
requesters post the jobs to be done on the Amazon Mechanical Turk web page and let the 
workers choose one or more to complete for a monetary payment (Bell, 2010). 
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b. SETI@home 

Another example of Internet supported erowdsoureing, SETI@home was 
founded in 1999 and aims to use the eomputing power of the eomputers in a erowd to 
find any proof of extraterrestrial life. Seientists managing SETI@home regard the projeet 
supported by the erowd more important than their supereomputers beeause of the 
eomputing power within the erowd (Howe, 2009). 

C. VIRTUALIZATION 

Obviously erowdsoureing and virtualization are different aeademie diseiplines, 
and it ean be a little puzzling for the reader to jump direetly from erowdsoureing to 
virtualization. However because of this thesis’ interdisciplinary nature these two areas of 
study need to be explicitly stated here. 

Virtualization is the abstraction of computing resources such as processing power, 
storage and network bandwidth. It helps simulate software or hardware and creates a 
simulated environment, which is known as virtual machine (Scarfone, Souppaya and 
Hoffman, 2011). Virtualized environments can have one or more of these goals: 

• To allow any device connected to a network to access any network- 
enabled application, even if the device and the application were not 
designed to work compatibly. 

• To isolate two or more applications to provide security or to maintain 
network resources. 

• To isolate an application from the operating system to work with any other 
version of the operating system. 

• To increase the number of users an application can be used for support by 
running the application on different instances of the operating system. 

• To optimize the usage of a system by decreasing the time system resources 
remain idle. 

• To increase system availability via redundancy by guiding the user to a 
running system if the previous system fails (Kusnetzky, 2011). 

After a brief introduction to virtualization and its use for data centers, an overview 
of the types of virtualization to be used throughout the CSEV project will be provided in 
this section. 
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1, Virtual Machine Monitors (VMM) 

VMM is a piece of software that gives the abstraction between machine hardware 
and the virtual machine. VMM records every activity happening within the limits of the 
virtual machine. It provides resources when necessary, and it can also forbid the usage of 
resources. 

2. VMM Types 

To virtualize an operating system, all instructions should be executed by 
hardware, software or a combination of both. These combinations have formed different 
VMM models. The models presented in this thesis will be Type I and Type II VMM 
models. 


a. Type I VMM 

This type runs directly on the machine hardware; that is why this type of 
VMM is called “bare metal.” A Type I VMM would most likely be an operating system 
or kernel that can support virtual machines (Figure 1). It would perform scheduling and 
resource allocation for each virtual machine on the system. Processors should be in 
compliance with every virtualization requirement that is needed by Type I. This 
compliance should provide the necessary protection for the real system from virtual 
machine borne intrusions (DoD ESX Server Guide, 2008). 
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Type 1 Hypervisor 


Hypervisor 

Hardware 



Hypervisor 


Host OS 


Hardware 


Figure 1. Type I and type II VMM (From Thomas, 2013) 


b. Type II VMM 

This type of VMM runs on a host operating system and is limited to the 
operating system resources, such as memory management, processor scheduling, resource 
allocation and hardware drivers (Figure 1). Because of these dependencies any operating 
system-related security issue might affect the stability of the Type II VMM (DoD ESX 
Server Guide, 2008). 

3, Security Considerations in Virtualization 

The overall security of a virtualization solution is dependent on the security level 
of each of the components. These components could be the hypervisor, host computer, 
host operating system (OS), guest OSs, applications on the system and storage. 
Virtualization users should be sure about the security levels of these elements by taking 
appropriate measures such as controlling access to administrator privileges, having up-to- 
date software, performing monitoring and analysis of logs, using anti-malware software, 
using host-based firewalls and any other mechanism to prevent possible attacks. 

Having these security measures for virtualization may not suffice to secure a 
system, however, because the virtualization needs of organizations change in every 
situation, and each situation requires different security approaches. Here, we will dig 
deeper into these security approaches to clarify this concept and explain more about 
hypervisor security. 
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a. Hypervisor Security 

The hypervisor known as Virtual Machine Monitor needs to be secured 
using methods similar to those used to protect other software. The overall security of the 
virtualized system is directly linked to the virtualized management system. Such systems 
should be under absolute control of the administrators. For example when the 
administrator needs to connect to the virtualized system, remote access to administration 
interfaces should be restricted by a firewall. If the communication is carried by an 
untrusted network, data should be under encryption using Federal Information Processing 
Standard (FIPS) approved methods (Scarfone, Souppaya and Hoffman, 2011). 

Access should be limited to the hypervisor, especially if it is a bare-metal 
type hypervisor. Although most of the bare-metal hypervisor access methods are based 
on user name and password, some of them still offer additional methods that grant access 
to the hypervisor management interface. 

Unlike bare-metal hypervisors, hosted virtualization environments do not 
generally have access controls. Because of this lack of security measures, anyone who 
can install an application on the OS can manipulate the hypervisor. This vulnerability 
necessitates the policies for organizations specifying the privilege level of accessing the 
hypervisor. The following guiding rules can help implement the right policy for 
hypervisors. 

• Install all updates for the hypervisor as soon as they are released. 

• Protect network communications via authentication and encryption 
using FIPS 140-2 cryptographic modules. 

• Synchronize the virtualized environment to a trusted time server. 

• Remove all unused hardware connected to a host system. 

• Do not use hypervisor file-sharing systems if they are not needed. 
The file-sharing systems are considered possible attack vectors 
(Scarfone, Souppaya and Hoffman, 2011). 

Additionally, hosted virtualization means that more threats will be around 
the system because the hosting OS will possibly have some vulnerabilities in addition to 
hypervisor security concerns. Unnecessary applications on the host OS should be 
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removed because the security of each guest OS will be affected by the host OS security 
(Scarfone, Souppaya and Hoffman, 2011). 

So far the biggest concern of security personnel is hiding hypervisors from 
the eyes of attackers. However, hypervisors have certain characteristics that make 
attackers aware of their existence. The hypervisor’s interactions with file systems, 
registry and related virtual drives all give some information to potential attackers. To 
prevent such attacks against a hypervisor using virtualized systems, organizations should 
take into consideration the risks and vulnerabilities (Scarfone, Souppaya and Hoffman, 
2011 ). 

D. CLOUD COMPUTING 

According to the National Institute of Standards and Technology (NIST) 
Definition of Cloud Computing (Mell and Grance, 2009), cloud computing is a robust and 
dependable pool of network resources, which includes computing, storage, applications 
and databases. One of the most important characteristics of this pool is its rapidly 
releasable and on-demand nature. This system would require the least management effort 
and less service provider interaction (Mell and Grace, 2009). A graphic representation of 
the NIST cloud computing model is shown in Figure 2. 



Figure 2. NIST visual model of cloud computing (From Damiani, 2011) 
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1, Characteristics of Cloud Computing 

According to the NIST Definition of Cloud Computing, characteristics of this 
computing include on-demand self-service, broad network access, resource pooling, rapid 
elastieity and measured serviee. These characteristies make cloud computing more 
beneficial in terms of efficiency and innovation in comparison to the eurrent computing 
environment as shown in Table 1. 
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Cloud Benefits 

Current Environment 

• Improved asset utilization 
(server utilization > 60- 70%) 

• Aggregated demand and 
accelerated system consolidation 
(e.g.. Federal Data Center 
Consolidation initiative) 

• Improved productivity in 
application development, 
application management, 
network, and end-user devices 

• Eow asset utilization (server 
utilization < 30% typical) 

• Fragmented demand and 
duplicative systems 

• Difficult to manage systems 

Cloud Benefits 

Current Environment 

• Shift focus from asset 
ownership to service 
management 

• Tap into private sector 
innovation 

• Encourage entrepreneurial 
culture 

• Improve link to emerging 
technologies (e.g., devices) 

• Burdened by asset 
management 

• De-coupled from private sector 
innovation engines 

• Risk-averse culture 


Table 1. Cloud benefits: efficieney and innovation (From Takai, 2012) 


Several eloud eomputing benefits are detailed in the following paragraphs. 

On-demand self-service: The user ean alter unilaterally the system eapabilities 
sueh as eomputing, server and storage settings, if needed, and there is no need for 
interaetion with a Cloud Serviee Provider (CSP). 

Broad Network Access: Cloud capabilities are available for a wide variety of 
thick and thin clients through standard access methods. Those clients could be mobile 
phones, laptops, netbooks, tablet computers or personal digital assistants (PDAs) (Smoot 
and Tan, 2012). 

Resource pooling: End-user needs are the main factor that dynamically assigns 
and reassigns the computing sources of the CSP. Those resources could include storage, 
processing power, memory, network bandwidth and virtual machines. The CSP has 
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relative freedom in notifying the end-user of the aetual physieal loeations of provided 
resourees. End-users are thought to be able to aeeess these resourees through an intranet 
if they are internal users and through the Internet if they are outsiders (Smoot and Tan, 
2012 ). 

Rapid Elasticity: The CSP ean quickly change the system capabilities to both 
scale in and out according to the user needs. End-users mostly think that system 
capabilities to provision are unlimited and usable (Mell and Grance, 2009). 

Measured Service: Cloud computing capabilities are under the control and 
surveillance of the CSP, with the help of a measuring system that often operates on a pay- 
per-use basis. This system provides transparency of used service (storage, computing, 
bandwidth) for both the cloud provider and the end-user (Mell and Grance, 2009). 

2. Cloud Computing Deployment Models 

There are four deployment models of cloud computing: 

Public Cloud: This type of cloud is available to almost anyone in the crowd who 
can access the Internet. With the development of cloud technologies, service providers 
operating in this area are increased. Some widely known examples include Amazon’s 
Elastic Compute Cloud (EC2), Rackspace’s Cloud Offerings, and IBM’s BlueCloud 
(Winkler, 2011). While these providers primarily offer Infrastructure service, there are 
others that give Application layer service, such as Google’s AppEngine and Windows’ 
Azure Services platform. 

Erom a security perspective public clouds can be considered both secure and 
unsecure. They are considered secure because public clouds are mainly operated by large 
scale CSPs. Therefore they should have enough security measures, including access 
control, data ownership and encryption (Winkler, 2011). On the other hand, end-users 
leave their data in the hands of the provider not knowing whether it is secure or not. CSPs 
have no obligation to their customers regarding the location of the stored data. If data is 
stored offshore in another country, the data is expected to be subject to the laws of the 
hosting country (Winkler, 2011). 
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Private Clouds: Private clouds are hosted internally and basically serve only one 
organization. Unlike data on public clouds, data on private clouds are not mixed with 
external users’ data. However, organizations may want to provide data isolation to satisfy 
the needs of the organization’s own subunits (Winkler, 2011). Private clouds can be 
owned, maintained and operated by either the organization itself, a third party or a 
combination of both (Mell and Grance, 2009). 

From a security perspective private clouds have more constraints than public 
clouds because small scale organizations may not address the computation needs as do 
large scale CSPs operating public clouds. It would also be incorrect to assume that 
private clouds are more secure than public ones (Winkler, 2011). Considering that private 
clouds use virtualization to save more on computing resources, private cloud providers 
should obtain measures, such as hypervisor and virtual machine security, to secure the 
virtualization environment (Winkler, 2011). The point of operating private clouds is that 
we can address the security issues by ourselves and are free to use any further measures 
that we deem appropriate. We have the chance to implement the security architecture 
according to organizational needs. In this sense a private DoD cloud can employ stricter 
security measures than a private cloud that is owned by a business corporation. 

Community Clouds: The cloud infrastructure is created for the use of multiple 
independent organizations that have the same concerns (that is, security, mission, 
regulation, policy or compliance). The system may be owned and maintained by each of 
the organizations, a third party or a combination of them (Mell and Grance, 2011). This 
model presents a valuable opportunity for the organizational entities that have similar 
legal and compliance restrictions. Different levels of community clouds are being 
considered both by the governments of the United States and the European Union. 
Governments will benefit because inter-government business transactions are considered 
to be processes in a possessed environment and will cause no additional costs as does the 
Internet (Winkler, 2011). 

Hybrid Clouds: This cloud infrastructure can be a combination of two or more 
different cloud types, as shown in Figure 3. Here separate and different clouds remain as 

a unique entity, and each of them is linked to others via a technology that enables secure 
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data transmission (Mell and Grance, 2011). Hybrid clouds are generally preferred by 
entities that operate private clouds. The main reason for this preference could be either 
security related or financial. An entity such as the DoD can have its confidential data in 
the private cloud and store unclassified data in the public cloud. Here hybrid cloud 
infrastructures will allow the necessary data transfer of the organization (Winkler, 2011). 



Figure 3. Hybrid cloud (From Shilovitsky, 2013) 

E. CLOUD COMPUTING SERVICE MODELS 

Software as a Service (SaaS): The applications running on a CSP’s 
infrastructure are the services provided to the consumer. Those applications could either 
be accessed via thin clients, such as a web browser, or via the interface of software. The 
consumer has no privilege to change any settings of infrastructure, servers, operating 
systems, or storage except for some limited application configurations (Mell and Grance, 
2011). Moreover, consumers may not want to change those settings. Google’s GMAIL or 
Yahoo mail services can be considered examples of SaaS (Winkler, 2011). 

Platform as a Service (PaaS): The consumer is capable of using his own 
application or an application provided by the CSP, as well as the libraries, services and 
tools (Mell and Grance, 2011). The consumer has control only over the applications he 
uses. He does not and cannot control the infrastructure, operating systems or servers 
provided by the CSP. In this sense, the PaaS is similar to the SaaS model. However, the 
PaaS model is different because the consumer owns the application. Google App Engine 
could be an example of the PaaS model (Winkler, 2011). 
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Infrastructure as a Service (laaS): This service model has the most flexible 
components provided to the consumer. In this model consumers can change applications, 
storage components, operating systems, databases and even some limited networking 
entities such as host firewalls (Mell and Grance, 2011). Some CSPs, including Amazon, 
go further providing services that the consumer can access through a platform of routers, 
switches and data centers (Winkler, 2011). This model is compared to other cloud 
computing models in Figure 4. 



On-premise 

Environment 


Applications 


Data 

Runtime 


Middleware 


O/S 


Virtualization 

Servers 


Storage 


Networking 


Figure 4. 
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Comparison of service models (From Lau, 2011) 


From a security perspective the laaS model is preferable for an organization like 
the DoD. No matter which cloud type the DoD utilizes, the necessary solution seems to 
be the laaS model. 

F. ENTERPRISE NETWORK SECURITY 
1, Network Security Coucepts 

The term “network security” is derived from “computer security.” According to 
NIST, computer security comprises the necessary protection mechanisms to provide 
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confidentiality, integrity and availability of data being processed (Stallings and Brown, 
2008). These three terms are widely known as the CIA Triad, and they lay out the 
essential principles concerning data and information seeurity. The CIA Triad, shown in 
Figure 6, refers to the eonfidentiality, integrity and availability of data. Confidentiality 
avoids the unneeessary disclosure of information to unauthorized parties. Integrity 
protects information so that it cannot be changed in an unauthorized ma nn er. Availability 
makes sure that information is always available for authorized users and keeps the system 
in serviee (Stallings and Brown, 2008). 



Figure 5. The security triad (From Chou, 2012) 

2, Security Vulnerabilities, Threats and Countermeasures 

As former Seeretary of Defense Leon Panetta noted repeatedly, the next Pearl 
Harbor is expeeted to happen soon, but this time from the eyber domain (Panetta, 2012). 
Current Secretary of Defense Chuek Hagel also drew attention to the importanee of eyber 
seeurity from a global perspective (Hagel, May 2013). Indeed, providing eyber seeurity is 
firstly a maero level necessity. Aceording to the Advanced Cyber Threat Report cyber 
threats share almost the same importanee level as nuelear armament issues (Defense 
Seience Board, 2013). In this thesis study we will use an enterprise level approach and 
analyze vulnerabilities, possible threats and neeessary eyber eountermeasures to mitigate 
the seeurity risks related to eloud eomputing. 
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a. 


Security Vulnerabilities 


In the security context, when we refer to security vulnerabilities we mean 
the vulnerabilities of system resources such as computing power and storage. This 
resource could be damaged or changed in such a way that it differs from what it is 
supposed to be. The resource may be leaky, giving information to unauthorized parties. 
Also the resource could be unavailable or very slow, and it may not serve system users as 
expected (Stallings and Brown, 2008). 

Unnecessary open ports: An open port is used for communication 
between computer systems on a network. A designated software works on a single port 
(e.g.. Mail service works on port 25 on most computers). When a port is open it 
continuously listens for possible communications intended for it. If the service running 
on the port is unnecessary that port should be closed to decrease the vulnerability level. 

Unpatched systems: System security vulnerabilities exist in almost all 
computer systems and software. They are supposed to be patched by the vendors to avoid 
vulnerabilities because hackers/attackers look for holes in such systems to exploit them 
via malicious codes (Gregory, 2010). Most software vendors react quickly to distribute 
patches to fix the security holes, and system users are expected to apply those patches. 
When necessary patches are not installed on the system, it becomes vulnerable to possible 
threats. 


b. Security Threats 

A security threat is the possibility of an adverse condition affecting 
computer systems. This threat could be realized from outside the enterprise or even from 
within an enterprise by a disgruntled employee (Gregory, 2010). 

Denial of Service (DoS): The DoS prevents or limits the intended use of 
communication infrastructures. An attacker can scale his attack to a limited level such as 
the recording of security audits. Sometimes he aims to take the whole network down by 
disabling it or overloading the network with random messages to downgrade performance 
levels (Stallings and Brown, 2008). 
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A developed form of DoS attack is the Distributed Denial of Service 
(DDoS) attack, which targets network resources by overwhelming traffic. DDoS attacks 
could originate from thousands, or even hundreds of thousands of systems. Highly 
complicated DDoS attacks use a botnet (see Figure 7), which is a collection of zombie 
computers, controlled by botnet operators (Gregory, 2010). 


• J..-U 4 A revs A'!*-* 



Figure 6. Distributed Denial of Service attack (From Masikos et.al., 2004) 

Sequence Number: Sequence number attacks attempt to hijack or fail a 
TCP session between two parties by guessing the sequence number of any of the TCP 
packets and achieving a correct timing. The attacker then sends false packets to either one 
of the parties pretending to be a valid sender. 

Smurf: A smurf attack includes a large number of fake Internet Contol 
Message Protocol (ICMP) echo requests. The ICMP packets are sent to the broadcasting 
address of the target network, causing all the devices to respond with ICMP packets as 
well. The attacker changes the “from” part of the packets to the target system’s IP 
address. When all of the devices send replies to the echo request the target system gets 
overloaded (Gregory, 2010). 
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Spam: Spam attacks comprise a high volume of emails whieh mostly have 
eommereial origins. Spam on the Internet is estimated to aeeount for 90% of all email 
eommunieation. Spam aims to degrade the performanee of network deviees by evading 
frequently used spam fdters (Gregory, 2010). 

Phishing: Phishing is a type of spam, and it is performed by sending mails 
while masquerading as offieial parties sueh as banks, hospitals or government ageneies. 
After defrauding the mail reeipients, the attacker gathers some important personal 
information like eredit eard or soeial seeurity numbers (Gregory, 2010). 

SQL (Structured Query Language) Injection: SQL injection attacks are 
one of the most significant threats to websites and databases. This type of attack mainly 
aims to introduce some malicious input, such as SQL codes, to a website and then gather 
confidential or other sensitive information from the linked database. The basic cause of 
SQL injection attacks is insufficient input validation measures (Halfond and Orso, 2005). 
This type of attack succeeds when input from a website visitor is accepted as a database 
SQL query without being validated. The attacker then becomes able to perform his SQL 
query embedded in the input for the website. In this way the intruder can gather, modify 
and delete data in the database. Clearly it is a threat for all three domains of information 
security (i.e., confidentiality, integrity and availability). In our proposed CSFV project to 
be run on DREN, the CSFV website could be vulnerable to this kind of attack because of 
the nature of its web-based applications. 

Cross Site Scripting (XSS): An XSS threat resembles the previous threat 
of SQL injection in the way that a website lacks security measures to check the input 
coming from users. XSS targets the website as content defacement or DDoS attacks, 
whereas SQL injection aims to manipulate the database behind the website (Ernst, 2009). 
According to past research XSS attacks moved to the top of the cyber threat assessment 
in documents such as “SANS Top 25 Most Dangerous Software Errors” and Open Web 
Application Security Project (OWASP) lists, passing the famous buffer overflow attacks. 
Basically XSS attacks use special characters when giving input to Hyper Text Mark-up 
Language (HTML) documents such as adding <script> to inputs to invoke the 

JavaScripts interpreter. When the browser does not perform input validation, the attacker 
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becomes successful and finds ways to further exploit the website such as account 
hijacking, cookie poisoning and even Denial of Service (Shar and Tan, 2012). 

c. Security Countermeasures 

Encryption composes the essential part of network security and security 
countermeasures. It includes two main pieces of information security: Symmetric Key 
Encryption and Asymmetric Key Encryption. In short, symmetric encryption means 
having a single key for each cryptographic algorithm, whereas asymmetric encryption 
uses two different keys, one of which would be known by public (Diffie and Helman, 
1976). The other key is supposed to be kept secret by its owner and would be used to 
decrypt the messages that were previously encrypted by the other public key. Key 
distribution in symmetric encryption is known to be easy because there is only a single 
key to be controlled by two users. Although key distribution is more difficult in 
asymmetric ciphers, it is more secure. The common feature of both symmetric and 
asymmetric ciphers is that the algorithm would be known by everyone, but the key is 
supposed to be known just by owner as explained in Kerckhoffs’s principle (Kerckhoffs, 
1883). 

The network security concept also includes practical applications such as 
IPsec technology, firewalls and authentication (Tanenbaum, 2003). Some of these 
applications will be used as system security measures in the experimentation sections of 
this thesis. 

IPsec (IP Security): Being originally a communications security measure, 
IPsec was created to fill the security gap throughout Internet. The argument at the first 
point was to provide data security either end-to-end fashion or just on the network with 
unaware users. After long discussions among security experts a security model emerged, 
and it was designed to provide network level security (Tanenbaum, 2003). IPsec has two 
modes of operation, which are transport mode and tunnel mode. The advantage of tunnel 
mode is that it adds another IP layer onto the packet, making data transfer easier and 
concealing flow of data in a better way. 
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Firewalls: The need for firewalls emerged after fast improvement of 
networks by means of eonneetivity and speed. Espeeially when networks overeame the 
size of premises and started forming Wide Area Networks (WAN) with the need for 
better eonneetivity, network input-output eontrols became more important. Then firewalls 
started to be used (Stallings, 2008). Essentially a firewall is composed of two routers 
working as packet filters and an application gateway. The point here is to force all of the 
traffic—incoming and outgoing—to use the route through the firewall. This way the 
firewall will allow or prohibit certain IP packets depending on whether the packets are 
authorized or not. This allow-or-prohibit decision is made by using IP numbers and port 
numbers. Eor instance, firewalls should prohibit data traffic coming to port 23, which is a 
telnet port (Tanenbaum, 2003). 

Intrusion Prevention Systems (IPS): An IPS is a network-based 
Intrusion Detection System (IDS) with an additional capability of dropping packets and 
blocking traffic as well as detecting malicious traffic and sounding alarms. IPSs can 
either be in a form of host based or network based (Stallings, 2008). 

A host-based IPS can check packets depending on their signatures or by 
using heuristics. Signature checking is controlling the payloads coming with the packets. 
The drop or allow decision is made depending on the presence of malicious content. 
When heuristics are used, the IPS looks for anomalies and misbehaviors of packets which 
can be either a modification of system resources, privilege-escalation exploits, buffer- 
overflow exploits or access to email contact lists (Stallings, 2008). 

A network-based IPS is an inline device that has the capability of 
inspecting Transmission Control Protocol (TCP) packets by tearing them down. It applies 
this inspection on every incoming data flow, and when a malicious behavior is seen, all 
the future data packets pertaining to that data flow are dropped. Some of the techniques 
used by network-based IPS systems to find malicious packets are pattern matching, 
stateful matching and protocol anomaly (Stallings, 2008). An example of network-based 
IPS is SNORT, which is an open-source, network-based, intrusion prevention system. It 
can employ signature-based, protocol-based and anomaly-based inspection. 
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III. NETWORK DESIGN 


A. INTRODUCTION 

In this chapter a secure CSFV network design will be discussed, key network 
design questions will be asked, potential security vulnerabilities and threats specifically 
relevant to CSFV networks will be presented and the necessary network components for 
optimal system security will be explained. 

Before examining the network design, it is important to understand the following 
facts about the surrounding environment: 

• The games and the database infrastructure are not yet released at the time 
this chapter is being written, so the design principles in this document will 
refer to presentations, drafts or other kinds of documents related to CSFV 
studies of CSFV vendors or DARPA. 

• The network infrastructure will be focused on security design, which does 
not mean that performance factors of the network are totally ignored; 
rather they will be discussed optimally with a security emphasis. 

• This system will first be deployed on the NPS Intranet and then transferred 
to DREN. Design decisions will be made according to Defense 
Information Systems Agency (DISA) Security Technical Implementation 
Guides (STIG). 

• The necessary security measures such as the location of firewalls, usage of 
IPS or IDS, network segmentation for better security and specific services 
(reverse proxy) will be discussed in this chapter. More detailed design 
parameters such as operating systems, firewall-IDS rules, and 
virtualization technologies to be used in the CSFV network will be 
presented in Chapter 4. 

B. NETWORK DESIGN CONSIDERATIONS AND GUIDELINES 

Several network design publications were used as guidelines while creating the 
CSFV network. The first of those publications is written by the National Institute of 
Standards and Technology: NIST Special Publication (SP) 800-44, Guidelines on 
Securing Public Web Servers, explains how to operate public-facing web servers for 
organizations such as the DoD and the private sector. It presents general 
recommendations about web servers, including operating system (OS) choice. 
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virtualization of OSs and communication security between web servers and database 
servers. 

CSFV networks would run on DREN-owned infrastrueture, so the initial design 
prineiples should be also in eomplianee with the publieations, whieh set networking rules 
for DREN. Network Infrastrueture STIG (2007) and Web Server STIG (2006) are two 
publieations that we used to build our network. Aeeording to these doeuments an 
optimum level of network seeurity should be provided by the following seeurity 
measures: 

• DoD networks should be layered aeeording to the information seeurity 
levels that those layers eontain. 

• The security in-depth prineiple should be used in loeating the network 
eomponents. 

• DoD system administrators should install, maintain and operate IDS inside 
their networks with the eapability of logging. 

• Eirewalls and web proxies should be deployed for perimeter security. 

• Web servers and database servers should reside on separate devices. 

• Web servers should use Seeure Soekets Eayer (SSE) and Transport Eayer 
Security (TLS). 

C. NETWORK TOPOLOGY 

We had three main goals before starting to design this network: to create a 
topology that shows the physieal and logieal elements of the network; to seeure the 
network eomponents against the most eommon threats of the day and from ones possible 
in the near future; and to prevent those seeurity measures from degrading the throughput 
of the network. 

There were a eouple of issues in mind in the design proeess: 

• seeuring the network from both Internet and possible insider attaeks, 

• using a multi-layered seeurity approaeh to seeure sensitive and elassified 
information sueh as the database server, 

• having additional systems for logging, eneryption and intrusion deteetion 
(SANS Institute, 2003). 
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Figure 7. CSFV Network topology. 

To examine the architecture in our network, we focused on the following seven 
questions: 

• Why do we use virtualization technology for game servers and database 
servers? 

• Why are game servers and database servers designed to reside on separate 
physical servers rather than being virtualized on the same machine? 

• Why do we use IDS, not IPS? 

• Why do we use two separate IDSs? 
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• What is the design prineiple related to using two firewalls, and what are 
their roles? 

• What is our goal in using a reverse proxy? 

• Is eneryption neeessary in CSFV network design, and how will it 
function? 

D, SEGMENTED DESIGN 

In this section detailed answers will be given to the preceding questions by 
partitioning the network (Figure 7) and explaining it part by part. 

1. Border Router and Firewall 

There will be a router and a firewall at the point where our network connects to 
the Naval Postgraduate School (NPS) website (nps.edu), as shown in Figure 7. The router 
and firewall can be either separate devices, or they could be designed to reside on the 
same physical server as a multi-functional system. The decision on this location will be 
given at the implementation phase. 

When choosing the type of firewall, we had a couple of options. It could be a 
packet filter firewall, which would operate at Layer 3, a stateful inspection firewall 
operating at Layer 4 or a deep packet inspection firewall, which additionally inspects 
application level loads. A packet filter firewall would be a poor choice because this type 
of firewall accepts every packet without looking at the destination port. The third choice, 
a deep packet inspection firewall, would possibly create a choke point at the entrance of 
the network and decrease the throughput. A stateful inspection firewall was the optimal 
solution both for the IP packet inspection security and for the system performance. 
Choosing to use stateful inspection firewalls is also necessary in utilizing the second 
firewall, which comes behind the switch. The application level packet inspection job of 
the two firewalls would be executed by the IDSs. Again, this decision was based on 
system performance concerns, not to mention the high cost of deep packet inspectors or 
the technical difficulty in utilizing them effectively. 

The first firewall will be configured to inspect packets which are coming to the 
reverse proxy server that will be in the demilitarized zone (DMZ), whereas the second 
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firewall looks into the packets coming to the database server. This second firewall only 
allows the packets coming from the address of game servers to database server. In case of 
a compromise of the reverse proxy, the attacker will not be able to access the database 
server because of this second firewall behind the DMZ. 



Figure 8. Firewall design. 


2. IDS 

To further protect the required network additional elements, in this phase we had 
the option of using IPS, IDS or both. When we consider that IPS would inspect a packet 
and sometimes necessarily drop it, we identified this possibility as a drawback for 
network throughput by generating false alarms (i.e., false positives). That is the reason 
we chose to use IDS. IDS will stay on the network and watch the ongoing traffic without 
interfering. It will start an alarm when malicious packets or abnormal network activity are 
detected. IDS will inspect the packets by comparing them to attack signatures or pre¬ 
installed IDS rules (DISA, 2007). The reason we use two separate IDS devices is to 
provide security in depth throughout the network. While the first IDS is inspecting the 
traffic in the DMZ, the second IDS will operate in a more secure part of the network and 
will look for anomalies or attack signatures targeting the database server. 
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Figure 9. IDS deployment. 



3, Game Servers and Database Server 

Game servers in the DMZ will be virtualized on the same physical server to 
provide efficient resource utilization. The number of game servers will initially be two, 
and this initial design will test the systems in a simple infrastructure with as few negative 
factors as possible. Furthermore, the CSFV network would eventually be deployed on a 
DoD cloud (Dean, 2013), and a virtualized environment on the NFS network will help us 
find and solve any potential vulnerabilities related to virtualization before this final 
deployment. 

We plan to operate the game servers in a virtualized environment; however, the 
database server will reside on another physical server. The reason for this design is to 
have multiple security layers in the network and to prevent any attacker from gaining 
access to our database server after compromising a game server. It is basically a two-fold 
security measure. Firstly, we avoid a virtualization-related “escape attack,” in which an 
attacker easily jumps to another virtualized system after accessing one virtualized 
environment. Secondly, our design makes an attack more difficult by putting the database 
in the trusted layer of our network. 
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Figure 10. Database server. 

4, Reverse Proxy Server 

A reverse proxy will be running between the game servers and their clients. It will 
serve as a proxy server operating in the reverse direction. The clients of game servers will 
not know the IP address of the game servers; rather they will know the address of the 
reverse proxy server and communicate with it. Because reverse proxies are specially 
designed systems they are more trusted and secure than regular servers. 

Additional features of reverse proxies are caching and load balancing. Caching 
increases the speed of the network by keeping the most frequently used records-data and 
retrieving them upon request. Load balancing will distribute the traffic of Hyper Text 
Transfer Protocol (HTTP) and Hyper Text Transfer Protocol Secure (HTTPS) over the 
two game servers, which will allow us to increase the number of game servers as the 
number of gamers expands. Moreover a load-balanced server will withstand the high 
volume of requests during a possible DoS attack by distributing the workload to many 
servers. 



Figure 11. Reverse proxy server. 
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E, ADDITIONAL SECURITY MEASURES 

1. Encryption 

Data traffic between the reverse proxy server and its elients will be encrypted 
using SSL/TLS. The outcome traffic will be HTTPS which is, in short, an HTTP session 
encrypted with SSL/TLS. The only port that will be open is port 443 (DISA, 2006). 

It is also determined that enerypting only the communieation between server 
clients and the reverse proxy server would be enough. Other than that the traffie between 
the game servers and database server will not be enerypted to keep performance levels 
high. 


2. Authentication 

Another faet about SSL/TLS eneryption is that it will provide server/elient 
authentieation by exchanging digital signatures between the reverse proxy server and its 
client. When a gamer wants to aecess a game site SSL/TLS authentication will occur, and 
the browser of the gamer will handshake with the server via the server’s digital signature. 
This digital signature ean be provided in two ways: creating and getting it verified from a 
third party Certifieate Authority (CA) or by ereating and signing itself (Tracy, 2007). 
Here, the digital signature will not be provided by a third party, it will be created by the 
server itself. 

User authentication with passwords and user names will be provided by the 
gaming software. 
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IV. IMPLEMENTATION 


A. INTRODUCTION 

In the previous chapter we have mentioned facts about the network design and 
topology and explained the design process including the proper locations of network 
elements, necessary services to be used by those elements and security concepts to be 
applied to provide confidentiality, integrity and availability. We have also validated the 
deployment of separate subnets and security components according to the necessary 
documents of DISA-DoD. 

In this chapter we will explain how we implemented our system with a slight 
difference from the initial design. We will show the details, such as IP addressing¬ 
subnetting, server operating system selections, proper usage of the necessary network 
services, firewall rules and IDS rules for efficient network security. At the end we will 
perform a network penetration test with popular attack tools. 

We will not discuss the troubles we came across while implementing the firewall 
and IDS rules although there were many, and we spent a considerable amount of time 
troubleshooting them. In particular, Redhat license expirations, conflicts between firewall 
rules and reverse proxy encryption issues were some of those troubles that we needed to 
address. 
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B. 


GENERAL NETWORK INFORMATION 


I, Network Topology Implementation 


FIREWALL*1 


Figure 12. Subnets in the CSFV Network. 

Subnetting is neeessary in the networks to maintain seeurity. Our network 
elements are distributed through three subnets (Figure 12), which are 172.20.104.0, 
10.0.0.0 and 192.168.0.0. While nps.edu maintains a subnet of 255.255.0.0 for the 
172.20.104.0 network, the author used 255.255.255.0 subnet both for 10.0.0.0 and 
192.168.0.0 networks. The main idea behind having separate subnets is to provide 
security in depth and to have a security-enhanced network architecture. 

After creating the initial design for the CSFV network architecture we decided to 
make some small changes on the first design. The first of those changes is to remove the 
border router and replace it with the reverse proxy.(Figure 13) With this change the 
landing machine of the network becomes the reverse proxy, which also runs a firewall on 
itself. By moving the reverse proxy to a different network than the game servers, we aim 
to avoid a possible attack scenario that can compromise the game servers by estimating 
their IP address range. Because those servers will be on separate networks, the attacker 
will not easily use a network scanner (such as nmap) and get access to the game servers. 

The second change to the initial design is to configure the second IDS as a host- 
based IDS, rather than a network-based IDS. With this change our goal is to run the first 
IDS to detect network-based attacks such as man-in-the-middle, packet sniffing and 
network scanning, whereas the second IDS is to be run on a server (database server) and 
detect the attacks, such as DDoS and password attacks. 
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2, Implementation of Servers 

There are a total of four servers, two IDS maehines and two firewalls in the CSFV 
network. Each of them is either virtualized on a physical server or not virtualized, 
depending on its usage. For example, the reverse proxy server stays at the entrance of the 
network as a border router and forwards traffic back and forth. Because it also runs a 
firewall on it, we gave it a separate non-virtualized machine. On the other hand, the 
backend servers, which we use as game servers, run on a virtualized environment called 
Vmware ESXi. 
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SSH fix the host has been enabled 


General 


Manufecturer; 
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License: 
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Logical Processors: 
Hyperthreading: 
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vMotion Enabled; 
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PowerEdge 1950 
8 CPUs X 2,66 GHz 
Intel(R) Xeon(R) CTU 
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Evaluation Mode - 


CPU usage; 50 MHz 
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[Evaluation Mode: 15days remaining 


Figure 14. VMware ESXi vSphere Client. 


We used VMware ESXi as the bare-metal operating system to virtualize the game 
servers and to make the network more efficient. As DISA STIG about VMware ESXi 5 
requests, we installed and maintained the server and database operating systems through 
ESXi shell and the software called vSphere Client (Eigure 14). 

In this process the usage of ESXi shell was very helpful because it can be 
managed by connecting through a secure shell (Eigure 15). ESXi shell is useful because it 
does not need a direct connection with the ESXi virtualization server. It is enough to have 
a remote connection to reverse proxy and use secure shell to access the virtualization 
server. 
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0 O O wg — root@BACKHAND:/var/www/html — ssh — 80x24 


sh-3.2# ssh -I root 10.0.6.3 
Password: 

The time and date of this login have been sent to the system logs. 

VMware offers supported, powerful system administration tools. Please 
see www.vmware.com/go/sysadm1ntools for details. 

The ESX1 Shell can be disabled by an administrative user. See the 
vSphere Security documentation for more Information. 

~ # 


Figure 15. VMware ESXi eommand shell. 


VIRTUALIZED SYSTEMS ON CSFV NETWORK 

VM 

NAME 

ROLE 

HOSTNAME 

IP ADDRESS 

OPERATING SYSTEM 

ESXi 1 

WEB SERVER 

csfvS 

10.0.0.234 

RED HAT ENTERPRISE 

LINUX 6.4 

ESXi 1 

WEB SERVER 

csfvS 

10.0.0.235 

RED HAT ENTERPRISE 

LINUX 6.4 

ESXi 2 

IDS - 1 

swing 

10.0.0.236 

RED HAT ENTERPRISE 

LINUX 6.4 

ESXi 3 

DATABASE SERVER 

and IDS-2 

csfv7 

192.168.0.11 

RED HAT ENTERPRISE 

LINUX 6.4 


Table 2. Virtualized systems. 


As it is seen from the Table 2, there are three bare-metal virtualization operating 
systems in the network. ESXi-2 runs the game servers at 10.0.0.0 network, ESXi-1 runs 
the first IDS server at 10.0.0.0 network and ESXi-3 runs the database server and the 
seeond IDS server at 192.168.0.0 network. 

The non-virtualized systems (Table 3) eonsist of a reverse proxy server and 
firewall server, whieh run on the CentOS 6.4 operating system. They use CentOS beeause 
the first CSFV systems, whieh would run on Amazon eloud arehiteeture, EC2, would 
have Centos as a server operating system. CentOS shares the same souree eode as Red 
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Hat, and the main difference between them is that the necessary update packages are 
publicly open source (Red Hat Enterprise Linux Installation Guide, 2013). 


NON-VIRTUALIZED SYSTEMS ON CSFV NETWORK 

ROLE 

HOSTNAME 

IP ADDRESS 

OPERATING SYSTEM 

REVERSE PROXY+ 

FIREWALL 

csfv4 

172.20.104.233 

CENTOS 6.4 

FIREWALL-2 

second 

chance 

10.0.0.21 

CENTOS 6.4 


Table 3. Non-virtualized Systems. 


Additionally, we downloaded and installed the necessary software packages from 
Red Hat repository to run the games appropriately. The necessary coordination was done 
with the contactor from TopCoder (CSFV PI Meeting, 2013). In total, 16 packages are 
displayed in this chapter, and they are installed particularly to run the games. The 
remaining 422 packages, which are necessary for any other Linux box, are shown in the 
Appendix. 
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collectd.x86 64 

4.10.9-l.el6 

@epel 

epel-release.noarch 

6-8 

@epel 

gccxml.x86 64 

0.9.0-0.12.20120309 .el6 

@epel 

ius-release.noarch 

1.0-11.ius.el6 

@ ius 

joe.x86_64 

3.7-4.el6 

@epel 

kernel.x86 6 

2.6.32- 

220.17.1.el6.centos.plus 

@centosplus 

kernel.x86 64 

2.6.32- 

358.6.1.el6.centos.plus 

@centosplus 

kernel-devel.x86 64 

2.6.32- 

220.17.1.el6.centos.plus 

@centosplus 

kernel-devel.x86 64 

2.6.32- 

358.6.1.el6.centos.plus 

@centosplus 

kernel- 

firmware.noarch 

2.6.32- 

358.6.1.el6.centos.plus 

@centosplus 

kernel- 

headers.x86 64 

2.6.32- 

358.6.1.el6.centos.plus 

@centosplus 

links.x86 64 

1:2.2-12.el6 

@epel 

mongo-10gen.x86 64 

2.4.3-mongodb 1 

@lOgen 

mongo-1Ogen- 
server.x86 64 

2.4.3-mongodb 1 

@ lOgen 

nginx.x86 64 

1.4.1-1.el6.ngx 

@nginx 

xmlstarlet.x86 64 

1.3.1-1.el6 

@epel 


Table 4. Necessary packages from CentOS repository 


3. Running Firewall Rules 

The CSFV network uses the Linux IPtables application that is embedded on the 
Red Hat/CentOS operating systems to define firewall rules for the firewall servers. We 
chose to use the Linux IPtables feature because it does not need any additional hardware 
or software, which would incur additional cost; it is a powerful tool used world-wide, and 
it is flexible enough to give the system administrator a wide area of rule options. 

IPtables operates by using the “TABLE” concept, which has “CHAINs”. The two 
main tables are “NAT” and “FILTER.” The NAT table has PREROUTING, 
POSTROUTING and OUTPUT chains. On the other hand, the FILTER table includes 


41 




INPUT, OUTPUT and FORWARD chains. IPtables also has the feature of user-defined 
rules. 


Our IPtables rules include two tables. The “NAT” table provides the network with 
Network Address Translation (NAT) to access outside of the network. It is also a tool to 
enhance seeurity and availability of the network. The NAT rules make the servers inside 
our network access the IP range outside of the CSFV network by getting different IP 
addresses. 

The FILTER table does most of the work in the network. It aceepts certain IP 
addresses and ports, drops unwanted IP traffic for security or performance reasons and 
logs the IP packets, whieh were dropped for further inspeetion. 

Our first firewall (csfv4.ern.nps.edu) has the rules to aceept incoming valid 
packets. It is set to allow the incoming traffic to the server’s 22 and 443 ports. 

-A INPUT -s 0/0 -i ethO -d 172.20.104.233 -p TCP —dport 

443 -j ACCEPT 

-A INPUT -s 0/0 -i ethO -d 172.20.104.233 -p TCP —dport 

22 -j ACCEPT 

-A INPUT -p icmp -j ACCEPT 

-A INPUT -p top -m state —state RELATED,ESTABLISHED -j 
ACCEPT 

-A OUTPUT -s 172.20.104.233 -o ethO -d 0/0 -p top —sport 
22 -j ACCEPT 

-A OUTPUT -p top -m state —state NEW,RELATED,ESTABLISHED - 
j ACCEPT 

-A FORWARD -p top -m state —state RELATED,ESTABLISHED -j 
ACCEPT 

-A FORWARD -p top —dport 22 -m state —state 
RELATED,ESTABLISHED -j ACCEPT 
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Csfv4.ern.nps.edu has the rules to drop the invalid paekets, spoofed paekets, 
XMAS scan packets and NULL scan packets, which are techniques for port scanning. 

-A INPUT -m state —state INVALID -j DROP 
-A FORWARD -m state —state INVALID -j DROP 
-A OUTPUT -m state —state INVALID -j DROP 

-A INPUT -s 10.0.0.0/24 -i ethO -d 172.20.104.233 -p tap - 
j DROP 

-A INPUT -s 192.168.0.0/24 -i ethO -d 172.20.104.233 -p 

tap -j DROP 

-A INPUT -s 10.0.0.0/24 -i ethO -d 172.20.104.233 -p udp - 
j DROP 

-A INPUT -s 192.168.0.0/24 -i ethO -d 172.20.104.233 -p 

udp -j DROP 

-A INPUT -p tap — tcp-flags ALL ALL -j DROP 
-A INPUT -p tap — tcp-flags ALL NONE -j DROP 


We used also DROP policies to define a default rule for packets. 


-P INPUT DROP 
-P OUTPUT DROP 
-P FORWARD DROP 

For logging dropped packages: 

-A INPUT -m limit —limit 15/minute -j LOG — log-level 4 — 
log-prefix "DROPPED PACKETS_FIRUZ: " 
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The second firewall, “Second Chance,” has the rules for allowing the traffic 
between the game servers and the database server and drop else. 


Rules to accept necessary packets: 


-A INPUT -s 10.0.0.1 -i ethO -d 10.0.0.21 -p TCP —dport 
22 -j ACCEPT 

-A OUTPUT -s 10.0.0.21 -o ethO -d 10.0.0.1 -p tcp —sport 
22 -j ACCEPT 

-A OUTPUT -s 10.0.0.21 -o ethl -d 192.168.0.11 -p TCP — 
sport 22 -j ACCEPT 


-A INPUT -s 192.168.0.11 -i ethl -d 10.0.0.21 -p tcp — 
dport 22 -j ACCEPT 

-A INPUT -p tcp -m state —state RELATED, ESTABLISHED -j 
ACCEPT 

-A OUTPUT -p tcp -m state —state NEW, RELATED, ESTABLISHED - 
j ACCEPT 


-A FORWARD -p tcp -m state —state RELATED,ESTABLISHED -j 
ACCEPT 

-A FORWARD -p tcp —dport 22 -m state —state 

RELATED,ESTABLISHED -j ACCEPT 

-A FORWARD -s 10.0.0.234 -d 192.168.0.11 -p tcp --dport 
27017 -m state —state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -s 10.0.0.235 -d 192.168.0.11 -p tcp --dport 
27017 -m state —state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A OUTPUT -p icmp -j ACCEPT 


The rule to log malicious or unnecessary traffic: 

-A INPUT -m limit —limit 15/minute -j LOG — log-level 4 — 
log-prefix "DROPPED PACKETS_FIRUZ: " 

Rules to drop invalid packets: 

-A INPUT -m state —state INVALID -j DROP 
-A FORWARD -m state —state INVALID -j DROP 
-A OUTPUT -m state —state INVALID -j DROP 
-P INPUT DROP 
-P OUTPUT DROP 
-P FORWARD DROP 

4 . Reverse Proxy Deployment 

As mentioned previously, the reverse proxy is implemented outside of the 
10.0.0.0 network. It is done this way to provide more security by letting game servers 
stay on a subnet other than the reverse proxy. 
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An Apache web server was configured to provide the reverse proxy function. 
When a user types “csfv4.ern.nps.edu” in his browser, our web server directs this request 
to one of the game servers and gathers the data by load balancing the user requests. 

The Apaehe eonfiguration rules, whieh reside at /var/httpd/conf/httpd.conf, enable 

the Apache server to transfer the files from game servers to the users and to load balance 

the requests. We added these rules to the configuration file of Apaehe on 

csfv4.ern.nps.edu: 

<IfModule mod_proxy.c> 

ProxyRequests Off 
<Proxy *> 

Order deny,allow 
Allow from all 
</Proxy> 

#The name of the load balancer Is "mycluster "which will 
#dlstrlbute all requests between 10.0.0.234 and 10.0.0.235 
<Proxy balancer://mycluster> 

BalancerMember http://10.0.0.234:80 
BalancerMember http://10.0.0.235:80 
</Proxy> 

ProxyPass / balancer://mycluster 

ProxyPreserveHost On 

ProxyVla On 

SSLProxyEnglne on 

ProxyPass / http://lO.0.0.234:80 

ProxyPass / http://10.0.0.235:80 

ProxyPassReverse / http://lO.0.0.234:80 

ProxyPassReverse / http://lO.0.0.235:80 

5 . IDS Deployment 

As we mentioned earlier, firewall rules will operate at layer 4, inspecting the 
socket pairs. Beeause we did not use a deep paeket inspeetion firewall to inspect the 
packet traffic at the applieation level, we should use an IDS deviee to watch the traffic 
above layer 4. We chose Snort as our network monitoring and IDS solution. 

Snort is an open source tool, which can serve as a sniffer, logger or a network- 
based intrusion deteetion system. There are many organizations around the world that use 
SNORT for intrusion detection. It is also used for protecting the DREN network on the 
NFS campus. 
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Snort has some rule sets as the default. In addition, other necessary packages can 
be installed or user-defined packages can be created (Alder, 2004). We used Snort’s 
predefined packages for the CSFV network. Being deployed both on the 10.0.0.0 subnet 
and 192.168.0.0 subnet. Snort will use a wide range of rule sets to detect malicious 
traffic, some of which are bad data traffic, exploits about mysql, sql injection, web 
attacks, DDoS, flash, chat and browser vulnerabilities. The Snort rules on CSFV network 
include; 

# include $SO_RULE_PATH/bad-traffic.rules 

# include $SO_RULE_PATH/chat.rules 

# include $SO_RULE_PATH/dos. rules 

# include $SO_RULE_PATH/exploit.rules 

# include $SO_RULE_PATH/icmp.rules 

# include $SO_RULE_PATH/imap.rules 

# include $SO_RULE_PATH/misc.rules 

# include $SO_RULE_PATH/multimedia.rules 

# include $SO_RULE_PATH/netbios.rules 

# include $SO_RULE_PATH/nntp.rules 

# include $SO_RULE_PATH/p2p.rules 

# include $SO_RULE_PATH/smtp.rules 

# include $SO_RULE_PATH/snmp.rules 

# include $SO_RULE_PATH/specific-threats.rules 

# include $SO_RULE_PATH/web-activex.rules 

# include $SO_RULE_PATH/web-cllent.rules 

# include $SO_RULE_PATH/web-iis.rules 

# include $SO_RULE_PATH/web-misc.rules 


6, Data Encryption 

Data encryption is implemented for the data in motion on the CSFV network. As 
previously stated SSL protocol is used to encrypt the data flowing between the game 
players and the reverse proxy server. Because port 80 would be closed on the firewall of 
csfv4.ern.nps.edu, all data traffic would go through port 443, which is used by HTTPS. 
The data traffic on the CSFV network, however, will be unencrypted going through port 
80. Here, the idea is that if we encrypt the moving data inside the network it needs to be 
decrypted on the reverse proxy server, re-encrypted and served to the clients. If a 
malicious user can get to the reverse proxy server as the man-in-the-middle he can also 
process the data, and the security would be worthless (Kew, 2003). Thus; we use SSL 
encryption between clients and the reverse proxy server. 
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The necessary SSL module (mod ssl) for the CentOS operating system to encrypt 
the data traffic was downloaded from the CentOS repository (Figure 16). It runs as an 
Apache httpd module dependent. 


e o o 

wg — root@csfv4;-ssh — 83x40 


Instalted Packages 


Name 

mod sst 


Arch 

x86 64 


Epoch 

1 


Version 

2.2.15 


Retease 

28.el6.centos 


Size 

183 k 


Repo 

Installed 


From repo 

updates 


Summary 

SSL/TLS module for the Apache HTTP Server 


URL 

http://httpd.apache.org/ 


License 

ASL 2.0 


Description 

The mod_sst module provides strong cryptography for the 

Apache Web 


server via the Secure Sockets Layer (SSL) and Transport 
Security (TLS) protocols. 

Layer 

[root@csfv4 - 

-1# 



Figure 16. The SSL module for CentOS . 


7, System Validation via Penetration Testing Tools 

To test the capability of Snort, we directed some attacks on the 10.0.0.0 subnet. 
The first attack tool we used is Nmap, which is widely used to map networks by scanning 
ports and gathering port information. We scanned the 10.0.0.0 network range with Nmap 
and triggered Snort. 

The second tool we used to test Snort is Low Orbit Ion Cannon (LOIC). This tool 
sends thousands of tcp, udp or http packets to make DDoS attacks on specific IP 
addresses or web sites. It is widely used on Internet to attack targets. 

We used LOIC to perform attacks on the second game server’s (csfv6- 
10.0.0.235) port 80 using udp packets (Figure 17). This attack is also caught by Snort 
(Table 5). 
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Low Orbit Ion Cannon | When harpoons, air strikes and nukes fails | v. 1.0.7.0 
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9001 
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A cat Is file too. Oesudesudesu* 


80 |UDP B 1000 1 Watforrepty ^ 


j Port 

Method Threads 


<» faster Speed slower »> 



Idle 

Connecting Requesting 

Downbadiig 

Downloaded Requested 

Failed 


Figure 17. Attacking on the game server via LOIC. 
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SNORT ALERTS 

1 

[**] [1:100000160:2] COMMUNITY SIP TCP/IP message 

flooding directed to SIP proxy [**] 

[Classification: Attempted Denial of Service] 

[Priority: 2] 

08/04-04:54:48.095433 10.0.0.235:593 -> 

10.0.0.51:34225 

TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:40 DF 
***A*R** Seq: 0x0 Ack: 0xF97CB988 Win: 0x0 TcpLen: 20 

2 

[**] [1:100000160:2] COMMUNITY SIP TCP/IP message 

flooding directed to SIP proxy [**] 

[Classification: Attempted Denial of Service] 

[Priority: 2] 

08/04-04:54:48.095960 10.0.0.51:34225 -> 

10.0.0.235:1084 

TCP TTL:55 TOS:0x0 ID:23251 IpLen:20 DgmLen:44 
******S* Seq: 0xF97CB987 Ack: 0x0 Win: 0x400 

TcpLen: 24 

TCP Options (1) => MSS: 1460 

3 

[**] [116:59:1] (snort_decoder): Top Window Scale 

Option found with length > 14 [**] 

[Priority: 3] 

08/04-04:54:49.016109 10.0.0.51:60511 -> 10.0.0.235:1 

TCP TTL:52 TOS:0x0 ID:51460 IpLen:20 DgmLen:60 
**U*p**F Seq: 0x6BC901C6 Ack: 0xBAB16756 Win: OxFFFF 
TcpLen: 40 UrgPtr: 0x0 

TCP Options (5) => WS: 15 NOP MSS: 265 TS : 4294967295 0 

SackOK 

4 

[**] [122:1:0] (portscan) TCP Portscan [**] 

[Priority: 3] 

08/04-04:55:44.906805 10.0.0.51 -> 10.0.0.2 

PROTO:255 TTL:0 TOS:0x0 ID:27082 IpLen:20 DgmLen:160 
DF 

5 

[**] [1:100000160:2] COMMUNITY SIP TCP/IP message 

flooding directed to SIP proxy [**] 

[Classification: Attempted Denial of Service] 

[Priority: 2] 

08/04-04:55:47.361994 10.0.0.51:40883 -> 

10.0.0.21:49157 

TCP TTL:53 TOS:0x0 ID:59640 IpLen:20 DgmLen:44 
******S* Seq: 0x4ClBBD2 Ack: 0x0 Win: 0x400 TcpLen: 
24 

TCP Options (1) => MSS: 1460 


Table 5. SNORT alerts 
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V. CONCLUSION 


A. SUMMARY AND CONCLUSION 

Manual formal software verification is an expensive and time-consuming process. 
The verification of military software is currently performed by highly skilled analysts 
(Dean, 2013). To reduce the high costs of the formal verification, DARPA started a 
Crowd-Sourced Formal Verification (CSFV) program in 2011. The goal of the program 
is to encourage as many people as possible to participate in this verification process by 
embedding some of the verification logics into computer games that are fun to play. 

In this study the CSFV network is designed and implemented according to the 
common security practices, necessary security measures against possible attacks, and 
DISA STIGs to configure network components. After validation and verification steps we 
observe that the system is working well with all its security elements, and it can be 
trusted to deploy on a secure DoD network. We recommend that the DoD install and 
experiment with our CSFV network prototype on its systems. 

The main goal of this thesis study is to design and prototype a secure and robust 
infrastructure for CSFV games. After going through a review of the literature and 
carrying out the design and implementation steps, we conclude that our CSFV system 
prototype provides these key features: 

IP address filtering and NAT: Our CSFV system prototype provides IP address 
and port filtering with its firewall servers. First firewall rules are set to prevent network 
attacks by dropping spoofed, invalid and malicious packets, such as XMAS and NULL 
scan packets. Also the first firewall logs those malicious packets. Furthermore this 
firewall server provides network address translation rules to use a different set of IP 
addresses from those used by the external network. Our second firewall, on the other 
hand, allows communication only between the game servers and the database server. This 
firewall provides a NAT solution as well. 

Network monitoring and intrusion detection: We implemented SNORT as an 
IDS on both 10.0.0.0 and 192.168.0.0 subnets to monitor the network activity. SNORT 
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uses a wide range of rule sets to detect malicious traffic, including sql injection, web 
attacks, DDoS, flash, and browser vulnerabilities. In Chapter IV we tested the network 
security levels with common attack/scan tools. 

Further security for game servers with a reverse proxy server: By deploying a 
reverse proxy server outside the CSFV network, we aimed to avoid direct communication 
between game players and the CSFV game servers. In our CSFV network prototype the 
reverse proxy server hands over the data from the game servers to the game players. In 
this way we tried to reduce the risk of compromise of any game servers. The reverse 
proxy also load balanced the game servers depending on the number of game players. 

Secure data transfer over SSL: All the game data flowing between the reverse 
proxy server and game players are encrypted by the SSL protocol, and they use port 443. 

B, FUTURE WORK AND CONSIDERATIONS 

This section presents further methods of increasing the security levels of the 
CSFV network prototype: 

• Currently game servers on the CSFV network are kept on the same subnet 
for the sake of network performance and simplicity. However, to provide 
even more security, each game server can be placed in separate subnets to 
prevent simultaneous compromise of the game servers. 

• There is a single database to store both game data and user data. A 
separate database can be designated only for user data to create another 
security layer for user privacy. Game data would then stay on a different 
database. 

• Network based attacks can be augmented including social engineering 
attacks and other network penetration tools. 

• Alternative scenarios can be created to isolate game servers from the 
reverse proxy in case of a compromise of the reverse proxy server. 
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APPENDIX 


The Necessary Yum Packages to Run CSFV Games; 


MAKEDEV.x86_64 

abrt.x86_64 

abrt-addon-kerneloops.x86_64 

abrt-libs.x86_64 

acl.x86_64 

alsa-lib.x86_64 

apr-util.x86_64 

audit-libs.x86_64 

atk.x86_64 

autoconf.noarch 

automake.noarch 

avahi-libs.x86_64 

basesystem.noarch 

bash.x86_64 

be.x86_64 

binutils.x86_64 

bison.x86_64 

btparser.x86_64 

bzip2.x86_64 

bzip2-libs.x86_64 

ca-certificates.noarch 

Cairo.x86_64 

cdparanoia-libs.x86_64 

centos-indexhtml.noarch 

centos-release.x86_64 

checkpolicy.x86_64 

chkconfig.x86_64 

cloog-ppl.x86_64 

compat-gcc-34.x86_64 

compat-gcc-34-g77.x86_64 

compat-libf2c-34.x86_64 

compat-libstdc++-296.i686 

compat-readlineS.x86_64 

cpio.x86_64 

cpp.x86_64 

cracklib.x86_64 

cracklib-dicts.x86_64 

createrepo.noarch 

cronie.x86_64 

cronie-anacron.x86_64 

crontabs.noarch 

CVS.x86_64 

cyrus-sasl.x86_64 

cyrus-sasl-lib.x86_64 

dash.x86_64 

db4.x86_64 

db4-utils.x86_64 

dbus.x86_64 

dbus-libs.x86_64 

dejavu-fonts-common.noarch 

dejavu-lgc-sans-mono-fonts.noarch 

dejavu-sans-mono-fonts.noarch 

deltarpm.x86_64 

device-mapper.x86_64 

device-mapper-event.x86_64 

device-mapper-event-libs.x86_64 

device-mapper-libs.x86_64 

device-mapper-multipath.x86_64 

device-mapper-multipath-libs.x86_64 

device-mapper-persistent-data.x86_64 

dhclient.x86_64 

dhcp-common.x86_64 


3.24-6.el6 

@base 

2.0.8-15.el6.centos 

@base 

2.0.8-15.el6.centos 

@base 

2.0.8-15.el6.centos 

@base 

2.2.49-6.el6 

@base 

1.0.22-3.el6 

@base 

1.3.9-3.el6 0.1 

@base 

2.2-2.el6 

@base 

1.28.0-2.el6 

@base 

2.63-5.1.el6 

@base 

1.11.1-4.el6 

@base 

0.6.25-12.el6 

@base 

10.0-4.el6 

@base 

4.1.2-14.el6 

@base 

1.06.95-1.el6 

@base 

2.20.51.0.2-5.36.el6 

@base 

2.4.1-5.el6 

@base 

0.17-l.el6 

@base 

1.0.5-7.el6 0 

@base 

1.0.5-7.el6 0 

@base 

2010.63-3.el6 1.5 

@base 

1.8.8-3.1.el6 

@base 

10.2-5.1.el6 

@base 

6-1.el6.centos 

@base 

6-4.el6.centos.10 

@base 

2.0.22-1.el6 

@base 

1.3.49.3-2.el6 

@base 

0.15.7-1.2.el6 

@base 

3.4.6-19.el6 

@base 

3.4.6-19.el6 

@base 

3.4.6-19.el6 

@base 

2.96-144.el6 

@base 

5.2-17.1.el6 

@base 

2.10-ll.el6 3 

@base 

4.4.7-3.el6 

@base 

2.8.16-4.el6 

@base 

2.8.16-4.el6 

@base 

0.9.9-17.el6 

@base 

1.4.4-7.el6 

@base 

1.4.4-7.el6 

@base 

1.10-33.el6 

@base 

1.11.23-15.el6 

@base 

2.1.23-13.el6 3.1 

@base 

2.1.23-13.el6 3.1 

@base 

0.5.5.1-4.el6 

@base 

4.7.25-17.el6 

@base 

4.7.25-17.el6 

@base 

l:1.2.24-7.el6 3 

@base 

l:1.2.24-7.el6 3 

@base 

2.30-2.el6 

@base 

2.30-2.el6 

@base 

2.30-2.el6 

@base 

3.5-0.5.20090913git.el6 

@base 

1.02.77-9.el6 

@base 

1.02.77-9.el6 

@base 

1.02.77-9.el6 

@base 

1.02.77-9.el6 

@base 

0.4.9-64.el6 

@base 

0.4.9-64.el6 

@base 

0.1.4-l.el6 

@base 

12:4.1.1-34.PI.el6.centos 

@base 

12:4.1.1-34.PI.el6.centos 
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diffutils.x86_64 

dmraid.x86_64 

dmraid-events.x86_64 

dracut.noarch 

dracut-kernel.noarch 

e2fsprogs.x86_64 

e2fsprogs-libs.x86_64 

ecj.x86_64 

ed.x86_64 

elfutils.x86_64 

elfutils-libelf.x86_64 

elfutils-libs.x86_64 

ethtool.x86_64 

file.x86_64 

file-libs.x86_64 

filesystem.x86_64 

findutils.x86_64 

fipscheck.x86_64 

fipseheck-lib.x86_64 

flex.x86_64 

fontconfig.x86_64 

fontpackages-filesystem.noarch 

foomatic.x86_64 

foomatic-db.noarch 

foomatic-db-filesystem.noarch 

foomatic-db-ppds.noarch 

gamin.x86_64 

gawk.x86_64 

gcc.x86_64 

gcc-c++.x86_64 

gcc-gfortran.x86_64 

gcc-gnat.x86_64 

gcc-java.x86_64 

gcc-objc.x86_64 

gcc-objc++.x86_64 

gdb.x86_64 

gdbm.x86_64 

gettext.x8 6_6 4 

ghostscript-fonts.noarch 

glib2.x86_64 

glibc.i686 

glibc.x86_64 

glibc-common.x86_64 

glibc-devel.x86_64 

glibc-headers.x86_64 

gnupg2.x86_64 

gpgme.x86_64 

gpm-libs.x86_64 

grep.x86_64 

groff.x86_64 

grubby.x8 6_6 4 

gstreamer.x86_64 

gstreamer-plugins-base.x86_64 

gstreamer-tools.x86_64 

gtk2.x86_64 

gzip.x86_64 

hicolor-icon-theme.noarch 

hwdata.noarch 

info.x86_64 

iproute.x8 6_6 4 

iptables.x86_64 

iputils.x86_64 

iso-codes.noarch 

java-1.5.0-gcj.x86_64 

j ava_cup.x8 6_6 4 

jpackage-utils.noarch 

kbd.x86_64 

kbd-misc.noarch 

keyutils-libs.x86_64 

kpartx.x86_64 

Icms-libs.x86 64 


2.8.1- 28.el6 
1.0.0.rcl6-ll.el6 
1.0.0.rcl6-ll.el6 
004-303.el6 
004-303.el6 

1.41.12-14.el6 

1.41.12- 14.el6 
l:3.4.2-6.el6 

1.1- 3.3.el6 
0.152-1.el6 
0.152-1.el6 
0.152-1.el6 
2:3.5-l.el6 
5.04-15.el6 
5.04-15.el6 
2.4.30-3.el6 
l:4.4.2-6.el6 
1.2.0-7.el6 
1.2.0-7.el6 
2.5.35-8.el6 
2.8.0-3.el6 
1.41-l.l.el6 
4.0.4-l.el6_l.l 

4.0-7.20091126.el6 
4.0-7.20091126.el6 
4.0-7.20091126.el6 
0.1.10-9.el6 

3.1.7- 10.el6 

4.4.7- 3.el6 

4.4.7-3.el6 

4.4.7-3.el6 

4.4.7-3.el6 

4.4.7-3.el6 

4.4.7-3.el6 

4.4.7- 3.el6 

7.2- 60.el6 
1.8.0-36.el6 
0.17-16.el6 
5.50-23.1.el6 

2.22.5- 7.el6 

2.12- 1.107.el6 

2.12-1.107.el6 

2.12-1.107.el6 

2.12-1.107.el6 

2.12- 1.107.el6 
2.0.14-4.el6 

1.1.8- 3.el6 

1.20.6- 12.el6 
2.6.3-3.el6 

1.18.1.4- 21.el6 
7.0.15-3.el6 
0.10.29-1.el6 
0.10.29-2.el6 
0.10.29-1.el6 
2.18.9-12.el6 

1.3.12- 18.el6 
0.11-l.l.el6 
0.233-7.9.el6 
4.13a-8.el6 
2.6.32-23.el6 
1.4.7-9.el6 
20071127-16.el6 
3.16-2.el6 
1.5.0.0-29.I.el6 
l:0.10k-5.el6 
1.7.5-3.12.el6 
1.15-11.el6 

1.15-11.el6 

1.4- 4.el6 
0.4.9-64.el6 
1.19-l.el6 


@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 

@base 
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less.x86_64 

libICE.x86_64 

libSM.x86_64 

libXll.x86_64 

libXl1-common.noarch 

libXau.x86_64 

libXcomposite.x86_64 

libXcursor.x86_64 

1ibXdamage.x8 6_6 4 

libXext.x86_6 4 

libXfixes.x86_64 

libXfont.x86_6 4 

libXft.x86_64 

libXi.x86_64 

libXinerama.x86_64 

libXrandr.x86_64 

libXrender.x86_6 4 

libXt.x86_64 

libXtst.x86_64 

libXv.x86_64 

libXxf86vm.x86_64 

libacl.x86_64 

libaio.x86_64 

libart_lgpl.x86_64 

libattr.x86_6 4 

libcap.x86_64 

libcap-ng.x86_64 

libcom_err.x86_64 

1ibdrm.x8 6_6 4 

libedit.x86_6 4 

libevent.x86_64 

libffi.x86_64 

libfontenc.x86_64 

libgcc.1686 

libgcc.x86_64 

libgcj.x86_64 

libgcj-devel.x86_64 

libgfortran.x86_64 

libgnat.x86_64 

libgnat-devel.x86_64 

1ibgomp.x8 6_6 4 

libgpg-error.x86_6 4 

libgudevl.x86_64 

libidn.x86_64 

libjpeg-turbo.x86_64 

1ibmng.x8 6_6 4 

libnih.x86_64 

libobjc.x86_64 

libogg.x86_64 

liboil.x86_64 

libpciaccess.x86_64 

libreport.x86_6 4 

libreport-compat.x86_64 

libreport-plugin-kerneloops.x86_64 

libreport-plugin-reportuploader.x86_6 4 

libreport-plugin-rhtsupport.x86_64 

libreport-python.x86_64 

libselinux.x86_64 

libselinux-utils.x86_64 

libsemanage.x86_6 4 

libsepol.x86_64 

libss.x86_64 

libssh2.x86_64 

libstdc++.x86_64 

libstdc++-devel.x86_64 

libsysfs.x86_64 

libtar.x86_64 

libthai.x86_64 

libtheora.x86_64 

libtiff.x86_64 

libtool.x86 64 


436-10.el6 

@base 

1.0.6-l.el6 

@base 

1.2.1-2.el6 

@base 

1.5.0-4.el6 

@base 

1.5.0-4.el6 

@base 

1.0.6-4.el6 

@base 

0.4.3-4.el6 

@base 

1.1.13-2.el6 

@base 

1.1.3-4.el6 

@base 

1.3.1-2.el6 

@base 

5.0-3.el6 

@base 

1.4.5-2.el6 

@base 

2.3.1-2.el6 

@base 

1.6.1-3.el6 

@base 

1.1.2-2.el6 

@base 

1.4.0-l.el6 

@base 

0.9.7-2.el6 

@base 

1.1.3-l.el6 

@base 

1.2.1-2.el6 

@base 

1.0.7-2.el6 

@base 

1.1.2-2.el6 

@base 

2.2.49-6.el6 

@base 

0.3.107-10.el6 

@base 

2.3.20-5.1.el6 

@base 

2.4.44-7.el6 

@base 

2.16-5.5.el6 

@base 

0.6.4-3.el6 0.1 

@base 

1.41.12-14.el6 

@base 

2.4.39-l.el6 

@base 

2.11-4.20080712cvs.1.el6 

@base 

1.4.13-4.el6 

@base 

3.0.5-3.2.el6 

@base 

1.0.5-2.el6 

@base 

4.4.7-3.el6 

@base 

4.4.7-3.el6 

@base 

4.4.7-3.el6 

@base 

4.4.7-3.el6 

@base 

4.4.7-3.el6 

@base 

4.4.7-3.el6 

@base 

4.4.7-3.el6 

@base 

4.4.7-3.el6 

@base 

1.7-4.el6 

@base 

147-2.46.el6 

@base 

1.18-2.el6 

@base 

1.2.1-l.el6 

@base 

1.0.10-4.I.el6 

@base 

1.0.1-7.el6 

@base 

4.4.7-3.el6 

@base 

2:1.1.4-2.I.el6 

@base 

0.3.16-4.I.el6 

@base 

0.13.1-2.el6 

@base 

2.0.9-15.el6.centos 

@base 

2.0.9-15.el6.centos 

@base 

2.0.9-15.el6.centos 

@base 

2.0.9-15.el6.centos 

@base 

2.0.9-15.el6.centos 

@base 

2.0.9-15.el6.centos 

@base 

2.0.94-5.3.el6 

@base 

2.0.94-5.3.el6 

@base 

2.0.43-4.2.el6 

@base 

2.0.41-4.el6 

@base 

1.41.12-14.el6 

@base 

1.4.2-l.el6 

@base 

4.4.7-3.el6 

@base 

4.4.7-3.el6 

@base 

2.1.0-7.el6 

@base 

1.2.11-17.el6 

@base 

0.1.12-3.el6 

@base 

1:1.1.0-2.el6 

@base 

3.9.4-9.el6 3 

@base 

2.2.6-15.5.el6 

@base 
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1ibudev.x8 6_6 4 

libusb.x86_64 

libuser.x86_64 

1ibutempter.x8 6_6 4 

libvisual.x86_64 

libxcb.x86_64 

libxslt.x86_64 

logrotate.x86_64 

lua.x86_64 

lvm2.x86_64 

lvm2-libs.x86_64 

lynx.x86_64 

m2crypto.x86_64 

m4.x86_64 

mailcap.noarch 

mailx.x86_64 

make.x86_64 

man.x86_64 

mcstrans.x86_64 

memcached.x86_64 

mercurial.x86_64 

mesa-dri-drivers.x86_64 

mesa-dri-filesystem.x86_64 

mesa-dril-drivers.x86_64 

mesa-libGL.x86_64 

mesa-libGLU.x86_64 

mingetty.x86_64 

mlocate.x86_64 

module-init-tools.x86_64 

mpfr.x86_64 

mutt.x86_64 

nano.x86_64 

ncurses.x86_64 

ncurses-base.x86_64 

ncurses-libs.x86_64 

neon.x86_64 

nspr.x86_64 

nss.x86_64 

nss-softokn.x86_64 

nss-softokn-freebl.i686 

nss-softokn-freebl.x86_64 

nss-sysinit.x86_64 

nss-tools.x86_64 

nss-util.x86_64 

nss_compat_ossl.x86_64 

openjpeg-libs.x86_64 

openssh.x86_6 4 

openssh-askpass.x86_64 

openssh-clients.x86_64 

openssh-server.x86_64 

pakchois.x86_64 

pam.x86_64 

pango.x86_64 

patch.x86_64 

pax.x86_64 

pcre.x86_64 

perl-Error.noarch 

perl-URI.noarch 

pinentry.x86_64 

pkgconfig.x86_64 

Plymouth.x8 6_6 4 

plymouth-core-libs.x86_64 

plymouth-scripts.x86_64 

policycoreutils.x86_64 

poppler.x86_64 

poppler-data.noarch 

poppler-utils.x86_64 

popt.x86_64 

portreserve.x86_64 

postfix.x86_64 

ppl.x86_64 


147-2.46.el6 

@base 

0.1.12-23.el6 

@base 

0.56.13-5.el6 

@base 

1.1.5-4.1.el6 

@base 

0.4.0-9.1.el6 

@base 

1.8.1-l.el6 

@base 

1.1.26-2.el6 3.1 

@base 

3.7.8-16.el6 

@base 

5.1.4-4.1.el6 

@base 

2.02.98-9.el6 

@base 

2.02.98-9.el6 

@base 

2.8.6-27.el6 

@base 

0.20.2-9.el6 

@base 

1.4.13-5.el6 

@base 

2.1.31-2.el6 

@base 

12.4-6.el6 

@base 

1:3.81-20.el6 

@base 

1.6f-32.el6 

@base 

0.3.1-4.el6 

@base 

1.4.4-3.el6 

@base 

1.4-3.el6 

@base 

9.0-0.7.el6 

@base 

9.0-0.7.el6 

@base 

7.11-8.el6 

@base 

9.0-0.7.el6 

@base 

9.0-0.7.el6 

@base 

1.08-5.el6 

@base 

0.22.2-4.el6 

@base 

3.9-21.el6 

@base 

2.4.1-6.el6 

@base 

5:1.5.20-2.20091214hg736b6a.el6 1. 

. 1 @base 

2.0.9-7.el6 

@base 

5.7-3.20090208.el6 

@base 

5.7-3.20090208.el6 

@base 

5.7-3.20090208.el6 

@base 

0.29.3-2.el6 

@base 

4.9.2-l.el6 

@base 

3.14.0.0-12.el6 

@base 

3.12.9-ll.el6 

@base 

3.12.9-ll.el6 

@base 

3.12.9-ll.el6 

@base 

3.14.0.0-12.el6 

@base 

3.14.0.0-12.el6 

@base 

3.14.0.0-2.el6 

@base 

0.9.6-l.el6 

@base 

1.3-9.el6 3 

@base 

5.3pl-84.1.el6 

@base 

5.3pl-84.1.el6 

@base 

5.3pl-84.1.el6 

@base 

5.3pl-84.1.el6 

@base 

0.4-3.2.el6 

@base 

1.1.1-13.el6 

@base 

1.28.1-7.el6 3 

@base 

2.6-6.el6 

@base 

3.4-10.1.el6 

@base 

7.8-6.el6 

@base 

1:0.17015-4.el6 

@base 

1.40-2.el6 

@base 

0.7.6-6.el6 

@base 

1:0.23-9.I.el6 

@base 

0.8.3-27.el6.centos 

@base 

0.8.3-27.el6.centos 

@base 

0.8.3-27.el6.centos 

@base 

2.0.83-19.30.el6 

@base 

0.12.4-3.el6 0.1 

@base 

0.4.0-l.el6 

@base 

0.12.4-3.el6 0.1 

@base 

1.13-7.el6 

@base 

0.0.4-9.el6 

@base 

2:2.6.6-2.2.el6 1 

@base 

0.10.2-11.el6 

@base 
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procps.x86 64 

3.2.8-25.el6 

@base 

psmisc.x86 64 

22.6-15.el6 0.1 

@base 

pth.x86 64 

2.0.7-9.3.el6 

@base 

pygpgme.x86 64 

0.1-18.20090824bzr68.el6 

@base 

python.x86 64 

2.6.6-36.el6 

@base 

python-deltarpm.x86 64 

3.5-0.5.20090913git.el6 

@base 

python-iniparse.noarch 

0.3.1-2.1.el6 

@base 

python-libs.x86 64 

2.6.6-36.el6 

@base 

python-pycurl.x86 64 

7.19.0-8.el6 

@base 

python-urlgrabber.noarch 

3.9.1-8.el6 

@base 

qt3.x86 64 

3.3.8b-30.el6 

@base 

readline.x86 64 

6.0-4.el6 

@base 

redhat-logos.noarch 

60.0.14-12.el6.centos 

@base 

redhat-lsb.x86 64 

4.0-7.el6.centos 

@base 

redhat-lsb-compat.x86 64 

4.0-7.el6.centos 

@base 

redhat-lsb-core.x86 64 

4.0-7.el6.centos 

@base 

redhat-lsb-graphics.x86 64 

4.0-7.el6.centos 

@base 

redhat-lsb-printing.x86 64 

4.0-7.el6.centos 

@base 

redhat-rpm-config.noarch 

9.0.3-42.el6 

@base 

rootfiles.noarch 

8.1-6.1.el6 

@base 

rpm.x86 64 

4.8.0-32.el6 

@base 

rpm-build.x86 64 

4.8.0-32.el6 

@base 

rpm-libs.x86 64 

4.8.0-32.el6 

@base 

rpm-python.x86 64 

4.8.0-32.el6 

@base 

rrdtool.x86 64 

1.3.8-6.el6 

@base 

rrdtool-devel.x86 64 

1.3.8-6.el6 

@base 

rrdtool-doc.x86 64 

1.3.8-6.el6 

@base 

rrdtool-perl.x86 64 

1.3.8-6.el6 

@base 

rrdtool-python.x86 64 

1.3.8-6.el6 

@base 

rrdtool-ruby.x86 64 

1.3.8-6.el6 

@base 

rrdtool-tcl.x86 64 

1.3.8-6.el6 

@base 

rsync.x86 64 

3.0.6-9.el6 

@base 

rsyslog.x86 64 

5.8.10-6.el6 

@base 

rubygems.noarch 

1.3.7-l.el6 

@base 

screen.x86 64 

4.0.3-16.el6 

@base 

sed.x86 64 

4.2.1-10.el6 

@base 

setup.noarch 

2.8.14-20.el6 

@base 

sgpio.x86 64 

1.2.0.10-5.el6 

@base 

shadow-utils.x86 64 

2:4.1.4.2-13.el6 

@base 

sinjdoc.x86 64 

0.5-9.1.el6 

@base 

sqlite.x86 64 

3.6.20-l.el6 

@base 

sudo.x86 64 

1.8.6p3-7.el6 

@base 

sysfsutils.x86 64 

2.1.0-7.el6 

@base 

sysstat.x86 64 

9.0.4-20.el6 

@base 

sysvinit-tools.x86 64 

2.87-4.dsf.el6 

@base 

tar.x86 64 

2:1.23-11.el6 

@base 

tcl.x86 64 

l:8.5.7-6.el6 

@base 

tcp wrappers-libs.x86 64 

7.6-57.el6 

@base 

time.x86 64 

1.7-37.1.el6 

@base 

tk.x86 64 

l:8.5.7-5.el6 

@base 

tmpwatch.x86 64 

2.9.16-4.el6 

@base 

tokyocabinet.x86 64 

1.4.33-6.el6 

@base 

udev.x86 64 

147-2.46.el6 

@base 

unzip.x86 64 

6.0-l.el6 

@base 

upstart.x86 64 

0.6.5-12.el6 

@base 

urlview.x86 64 

0.9-7.el6 

@base 

urw-fonts.noarch 

2.4-10.el6 

@base 

usermode.x86 64 

1.102-3.el6 

@base 

ustr.x86 64 

1.0.4-9.1.el6 

@base 

vim-common.x86 64 

2:7.2.411-1.8.el6 

@base 

vim-enhanced.x86 64 

2:7.2.411-1.8.el6 

@base 

vim-minimal.x86 64 

2:7.2.411-1.8.el6 

@base 

wget.x86_64 

1.12-1.8.el6 

@base 

which.x86 64 

2.19-6.el6 

@base 

xml-common.noarch 

0.6.3-32.el6 

@base 

xmlrpc-c.x86 64 

1.16.24-1209.1840.el6 

@base 

xmlrpc-c-client.x86 64 

1.16.24-1209.1840.el6 

@base 

xorg-xll-font-utils.x86 64 

1:7.2-11.el6 

@base 

xz.x86 64 

4.999.9-0.3.beta.20091007git.el6 

@base 

xz-libs.x86 64 

4.999.9-0.3.beta.20091007git.el6 

@base 

xz-lzma-compat.x86 64 

4.999.9-0.3.beta.20091007git.el6 

@base 
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yajl.x86_64 

1.0.7-3.el6 

@base 

yum.noarch 

3.2.29-40.el6.centos 

@base 

yum-metadata-parser.x86 64 

1.1.2-16.el6 

@base 

yum-plugin-fastestmirror.noarch 

1.1.30-14.el6 

@base 

yum-utils.noarch 

1.1.30-14.el6 

@base 

zip.x86 64 

3.0-l.el6 

@base 

zlib.x86 64 

1.2.3-29.el6 

@base 

zlib-devel.x86 64 

1.2.3-29.el6 

@base 

apr.x86 64 

1.3.9-5.el6 2 

@updates 

at.x86 64 

3.1.10-43.el6 2.1 

@updates 

bind-libs.x86 64 

32:9.8.2-0.17.rcl.el6 4.4 

@updates 

bind-utils.x86 64 

32:9.8.2-0.17.rcl.el6 4.4 

@updates 

coreutils.x86 64 

8.4-19.el6 4.1 

@updates 

coreutils-libs.x86 64 

8.4-19.el6 4.1 

@updates 

cups.x86 64 

l:1.4.2-50.el6 4.4 

@updates 

cups-libs.x86 64 

l:1.4.2-50.el6 4.4 

@updates 

curl.x86 64 

7.19.7-36.el6 4 

@updates 

dbus-glib.x86 64 

0.86-6.el6 

@updates 

elink.s.x86 64 

0.12-0.21.pre5.el6 3 

@updates 

expat.x86 64 

2.0.1-11.el6 2 

@updates 

freetype.x86 64 

2.3.11-14.el6 3.1 

@updates 

ghostscript.x86 64 

8.70-15.el6 4.1 

@updates 

git.x86 64 

1.7.1-3.el6 4.1 

@updates 

gmp.x86 64 

4.3.1-7.el6 2.2 

@updates 

gnutls.x86 64 

2.8.5-10.el6_4.1 

@updates 

initscripts.x86 64 

9.03.38-l.el6.centos.1 

@updates 

jasper-libs.x86 64 

1.900.1-15.el6 1.1 

@updates 

krbS-libs.x86 64 

1.10.3-10.el6 4.2 

@updates 

ksh.x86 64 

20100621-19.el6 4.3 

@updates 

libblkid.x86_64 

2.17.2-12.9.el6 4.3 

@updates 

libcurl.x86 64 

7.19.7-36.el6 4 

@updates 

libgcrypt.x86 64 

1.4.5-9.el6 2.2 

@updates 

libpng.x86 64 

2:1.2.49-l.el6 2 

@updates 

libproxy.x86 64 

0.3.0-4.el6 3 

@updates 

libproxy-bin.x86 64 

0.3.0-4.el6 3 

@updates 

libproxy-python.x86 64 

0.3.0-4.el6 3 

@updates 

libtasnl.x86 64 

2.3-3.el6 2.1 

@updates 

libuuid.x86 64 

2.17.2-12.9.el6 4.3 

@updates 

libvorbis.x86 64 

l:1.2.3-4.el6 2.1 

@updates 

Iibxml2.x86 64 

2.7.6-12.el6 4.1 

@updates 

libxml2-python.x86 64 

2.7.6-12.el6 4.1 

@updates 

mysql-libs.x86 64 

5.1.69-1.el6 4 

@updates 

net-tools.x86 64 

1.60-110.el6 2 

@updates 

openldap.x86 64 

2.4.23-32.el6 4.1 

@updates 

openssl.x86 64 

1.0.0-27.el6 4.2 

@updates 

passwd.x86 64 

0.77-4.el6 2.2 

@updates 

perl.x86 64 

4:5.10.1-131.el6 4 

@updates 

perl-CGI.x86 64 

3.51-131.el6 4 

@updates 

perl-ExtUtils-MakeMaker.x86 64 

6.55-131.el6 4 

@updates 

perl-ExtUtils-ParseXS.x86 64 

1:2.2003.0-131.el6 4 

@updates 

perl-Git.noarch 

1.7.1-3.el6 4.1 

@updates 

perl-Module-Pluggable.x86 64 

1:3.90-131.el6 4 

@updates 

perl-Pod-Escapes.x86 64 

1:1.04-131.el6 4 

@updates 

perl-Pod-Simple.x86 64 

1:3.13-131.el6 4 

@updates 

perl-Test-Harness.x86 64 

3.17-131.el6 4 

@updates 

perl-Test-Simple.x86 64 

0.92-131.el6 4 

@updates 

perl-devel.x86 64 

4:5.10.1-131.el6 4 

@updates 

perl-libs.x86 64 

4:5.10.1-131.el6 4 

@updates 

perl-version.x86 64 

3:0.77-131.el6 4 

@updates 

phonon-backend-gstreamer.x86 64 

l:4.6.2-26.el6 4 

@updates 

pixman.x86 64 

0.26.2-5.el6 4 

@updates 

qt.x86 64 

l:4.6.2-26.el6 4 

@updates 

qt-sqlite.x86 64 

l:4.6.2-26.el6 4 

@updates 

qt-xll.x86 64 

l:4.6.2-26.el6 4 

@updates 

rightscale.x86 64 

5.7.14-1 

installed 

ruby.x86 64 

1.8.7.352-10.el6 4 

@updates 

ruby-devel.x86 64 

1.8.7.352-10.el6 4 

@updates 

ruby-docs.x86 64 

1.8.7.352-10.el6 4 

@updates 

ruby-irb.x86 64 

1.8.7.352-10.el6 4 

@updates 

ruby-libs.x86 64 

1.8.7.352-10.el6 4 

@updates 

ruby-rdoc.x86 64 

1.8.7.352-10.el6 4 

@updates 
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ruby-ri.x86_64 
ruby-tcltk.x86_64 
subversion.x8 6_64 
tzdata.noarch 
util-linux-ng.x86_64 


1.8.7.352-10.el6_4 
1.8.7.352-10.el6_4 
1.6.11-9.el6_4 
2013b-l.el6 
2.17.2-12.9.el6 4.3 


@updates 

@updates 

@updates 

@updates 

@updates 
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